NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part1/2654

Internet Message Format | 1996-08-06 | 5.9 KB

Path: crc-news.doc.ca!usenet
From: Slobodan Celenkovic <[e-mail]>
Newsgroups: comp.lang.c++,comp.lang.pascal.delphi.misc
Subject: Re: C++ with Zapp vs. Delphi
Date: 18 Jan 1996 23:08:24 GMT
Organization: The Communications Research Centre
Message-ID: <4dmjt8$[e-mail]>
References: <4coar6$[e-mail]> <4coip7$[e-mail]> <[e-mail]> <4d7pmb$[e-mail]> <4dk38h$[e-mail]> <4dksp1$[e-mail]> <30fe666e.3349285@130.15.126.54>
NNTP-Posting-Host: celenkovic.bob.fob003.ic.gc.ca
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 1.1N (Windows; I; 16bit)

[e-mail] (Duncan Murdoch) wrote:
>On 18 Jan 1996 07:27:29 GMT, olczyk@sunphy1 (Jung Oh) wrote:
>
>>But it does raise an interesting problem.
>>How do you write a class SortedList which maintains a list of objects which
>>have a method CompareTo. This lists keeps the objects in sorted order based
>>on CompareTo.
>...
>>If you have MI it's easy. Just create a class called SortedObject with
>>a virtual method called CompareTo. Store objects of that type in the list.
>
>The way this is done in Delphi is to create a descendant of the
>SortedList that overrides the compare method.  Instead of forcing you
>to only put SortedObjects in the list, this allows you to put anything
>there, even non-objects like integers or strings or empty holes, if
>that suits your fancy.
>
>There's not a big difference, but I think this is a little bit
>preferable.  It makes it clear that it's up to the list to know about
>sorting, not up to the object.  That way you can easily put the same
>object in multiple lists with different sorting rules.
>

Nope, Jung is right. Consider (not strictly correct syntax):

Using Multiple inheritance (C++):
=================================

class AbstractItem
class IntItem(AbstractItem, some other class);      <- data classes
class StringItem(AbstractItem, some other class);
class MoneyItem(AbstractItem, some other class);

class SortedList ;

So here we have a single list and an item class for each item to be
stored in the list (plus the abstract)

AbstractItem includes:
function CompareItemTo(Item2 : AbstractItem) : integer;virtual;

So each item defines one or more comparison methods like:
(assume Pascal has function overloading)
<MoneyItem>
function CompareItemTo(Item2 : MoneyItem) : integer;virtual;
function CompareItemTo(Item2 : StringItem) : integer;virtual;
function CompareItemTo(Item2 : IntItem) : integer;virtual;

Consequences:

- additions/changes to the items (adding deleting an item class,...)
  requires NO changes to the list. If you think about it that is exactly
  what we want. Once the list is done we shouldn't have to go back
  and make any changes because of items.

- Each items defines HOW it is compared to other items, and CONTROLS to
  which items it may be compared. Again makes sense - the item classes
  should control what they can be compared with, i.e. which comparisons
  make sense.

No multiple-inheritance, no operator overloading -> Delphi:
===========================================================

We can't use the abstract item so:

class IntItem(some other class);      <- data classes
class StringItem(some other class);
class MoneyItem(some other class);

Instead we need a list class hierarchy with the comparison method:

class AbstractSortedList;

And then a class for each combination:

class StrStrSortedList(AbstractSortedList)
function CompareItems(i1,i2 : StringItem) : integer;virtual;

class IntIntSortedList(AbstractSortedList)
function CompareItems(i1,i2 : IntegerItem) : integer;virtual;


Consequences:

- A list class for each item class, hence we end up with twice as many
  classes. Furthermore we are placing some (little) item specific code
  into the list class; item specific code really belongs in the item
  class!

- A list may only contain a single type of item. The MI solution's list
  can store more than one type of item provided that the appropriate
  comparison functions are defined (so a list contain strings, integeres
  and money)


Well in that case might as well typecast:
=========================================

type ComparisonFunc : function(p1,p2:pointer) : integer;

class SortedList ;

Which would in the constructor get the appropriate comparison function as
a parameter:

Create(...., CmpFunc : ComparisonFunc);

And then list class can use it for searching, sorting,...)

Then create the function for each item:

function cmpInt(p1,p2:pointer) : integer;
var i1,i2 : IntegerItem ;
begin
  i1 := IntegerItem(p1);
  i2 := IntegerItem(p2);
comparison i1 & i2

Consequences:

- Again the same number of classes as the first case. In fact very
  similar, but still lists cannot combine items of different types
  (actually using a more sophisticated comparison function it could also
  be done). Also the item specific code is kept out of the list -> single
  list class.
- Not as elegant as #1.
- Very dangerous. It relies on the programmer's skill to ensure that the
  correct comparison function is supplied. Delphi's safe typecasting
  helps. Still programmer has to now what he is doing.


Finally to put the discussion into perspective. #1 is obviously the best
and most elegant solution. Yet even without MI (Delphi) it is doable. So
the price we pay in Delphi is that the solution is not quite as elegant.

I guess it all boils down to the size/type of project. Only the larger
projects using many classes will end up with this problem. Indeed then
C++ is more appropriate, that is when its extra firepower comes in handy.
However Delphi is designed for small/medium size apps, front ends, the
client side. There are not that many classes, they don't build some large
complex data structures,... so no need for the extras (MI, templates,
..). Instead they kept Pascal lean, rejecting the controversial
features. So Pascal is well suited for clients (GUI), C++ for servers.
Right?